So just to clarify, if this doesn't fix #611, what does it fix?

@lorenzodb1 This was uncovered while I was investigating #611. When I was investigating #611 I had some AWS secrets in my baseline. These secrets have a verify on them (We can reach out to an external to verify if they are truly secrets). After a recent change in the scan functionality for a regular scan - we pass in our context to lines we analyze so we can verify them.

Since we are reverse engineering a scan - we should pass the context in to analyze lines for an audit as well. This was not a known issue because context is a parameter for the analyze function with None default. So it worked fine until we hit the verify which occasionally requires a context (depending on the dependency injection).

So when it tried to audit a AWS secret - it was receiving a None context - causing an error.

@lorenzodb1 This was uncovered while I was investigating #611. When I was investigating #611 I had some AWS secrets in my baseline. These secrets have a verify on them (We can reach out to an external to verify if they are truly secrets). After a recent change in the scan functionality for a regular scan - we pass in our context to lines we analyze so we can verify them.

Since we are reverse engineering a scan - we should pass the context in to analyze lines for an audit as well. This was not a known issue because context is a parameter for the analyze function with None default. So it worked fine until we hit the verify which occasionally requires a context (depending on the dependency injection).

So when it tried to audit a AWS secret - it was receiving a None context - causing an error.

Good catch there! I'm wondering if we should add or modify a test case to better detect similar issues in the future?